Yeah, the test I wrote passes with or without this change. It's just this (based on https://github.com/irods/irods/blob/a9647277f3010ff5fe9123435bca68181d31b274/scripts/irods/test/test_python_rule_engine_plugin.py#L95-L108):

    @unittest.skipUnless(plugin_name == 'irods_rule_engine_plugin-python', 'only applicable for python REP')
    def test_CAT_SUCCESS_BUT_WITH_NO_INFO_is_treated_as_an_error__issue_7381(self):
        with append_native_re_to_server_config():
            with temporary_core_file(plugin_name=PYTHON_RULE_ENGINE_PLUGIN_NAME) as core_py:
                core_py.add_rule(dedent("""
                    import irods_errors
                    def myrule(*unused):
                        return irods_errors.CAT_SUCCESS_BUT_WITH_NO_INFO
                    """))
                self.user.assert_icommand(
                    ["irule", "-r", "irods_rule_engine_plugin-irods_rule_language-instance",
                     """writeLine("stdout", error("CAT_SUCCESS_BUT_WITH_NO_INFO") == errorcode(myrule()))""",
                     "null", "ruleExecOut"],
                    "STDOUT", ["true"])

Apparently returning the error code is not enough to trip that filter. I'm not really sure how to trigger a CAT_SUCCESS_BUT_WITH_NO_INFO in a way that's not a bug. Open to suggestions.

And your updated version of that test reloads server_config.json?
Have you tried calling IrodsController().reload_configuration() after the addition to core.py?

Then again, that may not matter since the PREP is already enabled and likely picks up changes to core.py.

I mean, I would expect a failure that the rule doesn't exist if reloading the configuration is required (because I updated core.py with a rule and then called the rule from the client side).

I know it's calling the rule because I discovered that the positional argument *unused is required for PREP rules since the machinery supplies 3 arguments when calling PREP rules and it was falling over for that reason while I was testing the test.

When CAT_SUCCESS_BUT_WITH_NO_INFO is returned from the rule, are you able to spot it in the debugger?

Can you track down why we originally ignored CAT_SUCCESS_BUT_WITH_NO_INFO?

When CAT_SUCCESS_BUT_WITH_NO_INFO is returned from the rule, are you able to spot it in the debugger?

I don't understand what you mean. I just know when the rule returns, the error code is returned in the calling rule.

Can you track down why we originally ignored CAT_SUCCESS_BUT_WITH_NO_INFO?

I traced it back to this commit, which seems to be the first time errors started getting handled: 33dcf82 There's no commit message or comment or issue attached.

Another idea is to write a test microservice which returns this error code and then call that in a rule from a test.

I don't understand what you mean. I just know when the rule returns, the error code is returned in the calling rule.

That question was coming from a gdb stance. I wanted to know whether the PREP rule was indeed returning the target error code.

And I think your comment answers my question.

I just know when the rule returns, the error code is returned in the calling rule.

I traced it back to this commit, which seems to be the first time errors started getting handled: 33dcf82 There's no commit message or comment or issue attached.

Another idea is to write a test microservice which returns this error code and then call that in a rule from a test.

Doesn't hurt to try.

If that doesn't work, we can open an issue for this and address it later. You've already confirmed that the existing tests pass, so we haven't introduced a regression as far as we know.

Yeah, that's gonna require some more thought. I created #240 to handle adding the test.

#'d, mergin